The Datafile PD-CD 1 Issue 2

home *** CD-ROM | disk | FTP | other *** search

/ The Datafile PD-CD 1 Issue 2 / PDCD-1 - Issue 02.iso / _comms / comms / _signature / AC / !Signature / !Help < prev next >

Wrap

Text File | 1993-02-04 | 23.7 KB | 552 lines

Open reply on NetMail, dated Sat,16 Jan 1993.18:13:58, sent From: Dirk-Willem van Gulik To: All Subject: Re: Signature 1.04 Help file for Signature. This is a TEST version. version 1.04 ⌐ 1993 Dirk-Willem van Gulik - supports interactive help - For conditions of use, see the end of this file. This program allows you to 'sign' and 'seal' text files with your personal signature. This seal/signature is attached to the text. Any changes made to the text will render this signature invalid. A public key list allows you to check signatures from other people. If you drag a signed message into this programme it will check the signature against the known public keys of the sender. This implies that the message must have a certain header (as WimpLink 0.96 supplies) which includes the sender. You will have to create a personal signature first with the programme 'maker' which accompanies this application. This programme will make both a secret and a public key. You can then distribute the public key freely. A 'public' file, which you can distrubute as a message is create in the same (root) directory as !Signature. As the secret password is stored on disc there is an option in the program to scramble it with a secret password. You should do this as soon as possible. Just run !Signature immediately. The programme will agressively ask for such a password, in fact it will refuse to do anything, until you have entered one. After this 'first-time-bad-behaviour' it should get into better moods, and bit will bhaves decently (I hope) on your sucsessive runs. This password is normally a sentence of about 15 words long. Special 'token' words will code the signature. The first time you run the programme '!Signature' after having used Maker, you will be prompted to enter a password. In the 'Change/Enter password' window you will find a 'token-word-list'. Only words from this list scramble your signature. Normally you would build a sentence around about 10 words chosen from this list. As an example you could make passwords like these: - He himself is a good rabbit. - London is no longer a good living place to look after. - Drink Driving is a stupid thing to do. As you will see only half of these words actually count, i.e. code your signature. You can see how many 'valid' words you entered by pressing on 'COUNT'. At least one word should be taken from the token list in order to make a password a valid password. If not, the programme will refuse to accept the password. After you have pressed the 'Change' button your signature will be coded and stored on disc. From then on you will be prompted to enter a password each time you run !Signature. This password is checked against the known public keys. After that it will be used together with the information on disk to sign any messages you drag into the programme. Be sure you remember your password as there is no way of recovering it, the 'private file', the password and at least one public key are needed to sign a message. If any of these gets missing there is no way of recovering it. You need both public keys to check the signature of someone else. After you have ran 'Maker', to create your signature, and !Signature, to enter your personal password, and you have distributed the 'public' key-file to your friends, you are ready to go.... The RSA Public key crypto system... In 1978 Rivest, Shamir and Adleman published a scientific paper which, in one brilliant stroke, made all problems with secret keys, reliable messengers and authorized channels history. They devized an asymetric coding scheme utilizing a set of three keys. One of these keys is a secret master key, the two other keys are known as the public keys. The scheme is called asymtric because coding and decoding is ruled by different keys. Depending on the way you use them you can either 'code' messages with the public key which can only be decoded by the secret key or you can de-code messages with the public key which can only be coded by the secret key. This last option is used in this Signature application. Because you 'cannot' reconstruct the secret key out of the public key this system does not rely on complicated exchanges of secret keys and passwords. This makes it possible for someone to distribute his public keys. The 'cannot' verb should not be taken too seriously, it is possible to do this reconstruction at the expense of an immense amounth of computer power. The amounth of power required relies on the lenght of the key. Signature can cope with long keys, up to 300 decimal digits. The last 'hack' reported on the RSA scheme was done by Manasse and Lemstra in 1990. Using massive parallel computer power they managed to break one individual signature of lenght 107. In the appendix you can find a short explanation of the RSA system, the way it works and how it can be broken. Brute force code breaking however is not a serious risk. Using something commenly known as 'human-engineering' one could fool people far more easier and cheaper. The famous example is of someone calling up and saying 'hello, this is your friendly bank manager speaking, we are having problems with our computer, and something is happening to your bank account. What is your Personal Identity Code ?' Using a 100 digits or more will certainly ensure that the 'technical side' of signing messages is dealt with and that the 'weakest' link must be found on the organizational/human half of the story. The signing procedure This procedure consists of three steps; Checksum creation, Coding and adding the signature to the message. The first step creates a unique number which is dependent on every single character in the message. Changing a single character will affect the checksum in a very unpredictable way. In this 'unpredictable' is the key-word. Up till version 1.04 use a technique classified as polinomal creation. Later version have a few more tricks up their sleeve. The reason for this is that the checksum is of cource shorter than the text. So there must be quite a number of different messages all with the same checksum. This means that in theory you could change a message and still have the same checksum. This would not be detected by the system. However the lenght of this checksum is equal to the length of the key. Because of the fairly 'inpredictable' way in which this checksum changes it is very hard to generate a message which is both meaningfull AND which has a specific checksum. Currently a length of 39 decimal digits is considered to be safe.... !Signature uses a checksum which has the same length as the secret key, in the order of 100 digits. This checksum is then coded using your very personal and secret key. The resultant chypher code is translated into reable ascii. This ascii string is added to the message. The receiver removes this string. Next it again calculates the checksum. Then it 'decodes' the signature using the known public keys of the sender. This should result in the vaule of the original checksum. This must match with the newly calculated checksum. If they do you can savely assume that the message is NOT altered and that the signature has been created by somone, the sender, who knew the secret key. As you will notice only 'public' information is used and created in this process. The checksum which is calculated is of cource public, because the receiver may read the message. The information extracted from the signature is again a checksum, which contains information about the message to which you already have acces to. Well that is the technical side.... now for the weak spots: ..... the secret key and all the values of the variables used whilst creating it must be kept secret. ..... the checksum must be long enough and must be so unpredictable that it is impossible to create a message given a certain checksum ..... the communication channel of the public key and messages must be safe. If not an attacker could intercept the public key and all messages send to you, send you his own public key, and resign all subsequent messages from then on. ..... during the coding oparation your system should be 'closed' ..... there is no way of checking whether a message arrives, so removal and repeated sending is possible. You can prevent this by numbering and dating the messages if this is important. Usage...... How to use this pogramme........... Outgoing mail: Simply write your messages as usual, using any editor, typically !Edit. After you have written them, drop them on the icon-bar- icon of !Signature to have them signed. After a few seconds and some hourglass fiddling a normal 'save-as' window will appear. Now you can drag the -signed- message to its destination, a filer, mail programme or editor. Of course you can always type out a full pathname and press the return key or 'OK' button. Incoming mail: Incoming mail should have a header. A typical header, like the one WimpLink (0.96) supplies looks like Private message on NetMail, dated Fri,04 Dec 1992.15:10:01 From: Dirk-Willem van Gulik To: Pieter Griessen Subject: Birthday party of Adriaan. The exact format of the header recognized can be changed in the 'preferences window'. If you drag a window with an appropriate header onto the icon-bar- icon of signature, an analyze window will pop up. This will inform you about the sender of the message. Whether her/his public key is known, whether the message is signed and if this signature matches the known public keys. To allow a greater degree of control you can open a more elaborate window. Just press SELECT on the iconbar icon. This will open a large window in the middle of your screen. You can use the interactive help to find your way around. Typically you can drag a message into the in-tray, right-hand-top-corner. Next you can have it signed, even if it is already signed, remove the last signature or check the signature. If there is no known sender to check the signature against, you can enforce one temporarily by choosing one from the list. You can gain access to a menu with a list of all known public-signatures owners by pressing select on the 'ë' button, to the right of the from field. You will see that the first entry in this public list has an arrow pointing to a leaf item. This window contains a whole host of information about your public key, the age of your password (keep it fresh!) and public list. Most notably there is also a report on the signature attachted by the list-distributor of the public list. Preferences: For the more expert user there is also a preference section. It can be reached by choosing the option 'Prefs...' in the menu. This will open a window with various options. Changing these will normally affect the format of your outgoing mail. This can cause serious trouble, because your Mailer, your Host and the people you send your mail to expect you to use a certain format. So do not change these setting, unless you are VERY sure about what you are doing. If a change is needed, for example because a new version of WL appears, you will be briefed by private netmail. ..>> To protect the inexpert user a nasty protection scheme has been ..>> employed. This 'prefs' option will not be visible, unless you open ..>> the menu whilst pressing 'shift'. This will ensure that ony people ..>> who have read this help-text will be able to access it. I am sorry ..>> if you find this tooooo paternalistic. The main reason for providing this option is to ensure that during the initial testing period certain characterstics can be changed. Future versions of this programme will most like have a more 'hidden' way of setting up things. Export line separators. The ascii end op line codes. Currently only lf and cr are supported. Most mailers accept both. Signature specification Specify the signature prefix. Currently set at '*Signature ['. Also whether to compress the signature-sequence. (saves about 62%) Header specification Specification of the header of incoming mail. Currently set to the values which match WimpLink version 0.96. After you have entered any values you can do three things: Press the CANCEL button; this removes all your changes and ignores them. Press the STORE button; this will (after confirmation) save the newly entered values to disc and use them on this and subsequent runs. Press the OkΘ button. This will use the newly entered values on the current run, but will NOT save them. Entering/Changing your password: As said you will have to enter your password. You can also change the password. There is a 'Password...' option in the menu. The password window consist of 4 parts. Use the interactive help to find your way around it quickly. Entry area: This is the white top rectangle. Here you type out your password. You can use the cursor-keys to find your way around. The editor however is not very advanced and certainly not up to the normal risc-os-standards. As soon as you have typed part of a word you will find that the token list scrolls to the nearest entry in the token list. You can click SELECT on the 'insert' button, or press tab to automagicaly insert a word from the token list. The more words from this list appear in the password-sentence, the better the coding of your secret signature will be. About 20% is really the minimum. Comment area: This is the small (yellowish) rectangle just below the entry area. It tells you about the things you are currently supposed to do... Count/Info area: Bottom lefthanded square. You can find some counts on the number of words and the number of token words in your password sentence. The more the better. Also the 'covering' percentage is displayed, ie what part of your signature is coded by the password sentence. TokenList: The bottom middle square. This is a list of thousand words. Each word has a number. Every word in your password sentence which can be found in the token list combines to on mega-long-number. This number codes your secret signature code. Count button: Press this button to update the count area. Cancel button: Cancel and close the password entry/change window. If you are entering a password for the first time in a run-session this will be aborted too. This means that the programme will refuse to sign messages. OkΘ/Change button: OkΘ-state: When you press this button the password sentence entered is translated into a long number. This number is combined with a number from the file 'private'. Together these will make your secret signature. Then this signature is checked against the known public keys. If they match, the password is accepted. This means that the programme checks the password without actually knowing the password! So you better not forget it because there is no-one who can get it back. Public List. Inside the !Signature application is a text file called 'List'. This file contains all the public keys known to the programme. As soon as you have ran 'maker' you will find your name added to that list along with the public keys. From time to time you will have to update this file. This will normaly require replaceing it by a new 'List' file. Use Shift-Double click on the application icon in the filer dir to open de directory inside !Signature. Rename the old 'List' into something like 'backup' and copy the new list into the directory. This is, by the way, the only flaw in this otherwise secure system of signing and sealing messages. It is absolutely required that you have an authorized, ie unalted and correct list of public keys. From version 1.04 onwards the list is checked for a public, hard-coded, distribution key. A future version of this programme, for serious use, will address this subject even further. Problems like this can, by matter of principle, not be solved by computer and mathematical tricks, and the solution is one of organizing and protocol agreements between people rather that computing. In order to make sure that your public keys, which are added to the list, are secure the following protocol is to be adhered to: - You should send the list distributor the file 'public' made by Maker. - The list distributor will return this message with his sign attached. - You check this signature using your secure list. You also check your keys which are quoted in the message against the ones stored in your private file. - Only and Only if they match, and if the signature of the message if oke, you send a confirmation to the list distributor, signed with your now fixed signature. - Your public keys will be added to the list and a new list will be send to all users. This list is of course signed. On receival of this list you will check it against the public keys of the OLD list. Only if everything is correct you are to replace the old list. The main safety measurement is keeping your system clean. First make sure you have a 'safe' version of the software. For the extrem schito-people, you can order one from the address below. Next you have to keep this version clean. This means 'locking' of the disc/directory, if possible, as on a floppy disc, using the 'hardware' write-protection thingy on the disc. Every time you get a new distribution list, check wether the sender and his or her signature is correct. If in doubt, get a few copies of the list, from several (BBS) sources, and check wether they have EXACTLY the same signature. Ctrl-Reset your machine before updating the list; do not use your harddisc, just a 'bare', 'clean' machine quite sufficient! Well that is all there is to it. Happy signing. ....................... W A R N I N G S ............................... WARNING for usersers of WimpLink 0.96 (and other versions perhaps) WimpLink substitutes the '{' characters into '{/123}' whilst exporting messages if the 'Impressionize Brackets' option is on. This is to make sure that Impression does not get confused by the '{' character, which normaly defines the start of a lay-out-token. However !Signature sees this as a change of the contents of the message, effectively '/123}' is added. So make sure that the impressionize options are OFF, or check the message (and signature) for '{' tokens if a 'non-match' occurs. A 'match' situation is always save, no matter the '{' characters or substitutions. WARNING for users upgrading from Signature 1.03 and below. There is always a certain trade-off between individual and system safety. After some discussion it has been deceided to change the balance a wee bit into the direction of the individual user. This means that in version 1.04 onwards a different password sentence coding system has been implemented. Full instructions can be found in a file update_103. Please study them carefully and follow then closely. ........................................................................ Boring section: This programme is (c) december 1992 by Dirk-Willem van Gulik. - C O N D I T I O N S O F U S E - Both the user and or the owner of the media this programme is stored upon, as well as the user and or the owner of the computer system this programme is loaded into agrees to the following conditions: This programme shall not be changed. All its files as listed below shall remain part of the programme unalterd and must be stored inside the !Signature application directory. This programme is ShareWare. It can be freely copied and used by private users for recreational purposes only. Provided that all files are kept unchanged and copied along. The 'Message' file can be changed and translated for personal use. However you should always keep the original and pass it on. The 'List' file can be updated. See below. Commercial use of this programme is prohibited. Commercial Distribution of this programme is prohibited. Public Domain Libraries are not allowed to distribute this programme. Usage and or distribution which bears profit, by means of money, goods, services and alike, to the user is prohibited. Any of these foregoing conditions can be lifted by a written permission from the author. PD Libs can obtain a special full version for distribution by writing a letter to the author. If you do not want to fulfil the conditions of use named above, please wipe all your copies of this programme. Files, Inside the directory !Signature: name: filetype: short description: !boot Obey !Help Text This Help text !Run Obey !RunImage Basic Main kernel of the programme !Sprites Sprite System sprites. *List Text Public list of keys. Update it as new lists of public keys become available. *Messages Text Messages. Currently english. Feel free to make translations or to improve this one. Send the author a copy please! Numbers Module Relocatable module doing all the heavy number stuff, from the Acorn User, Sep. 92. NumModTxT Text Explanation number module. prefs Data preferences RSA Basic libary for the coding stuff Sprites Sprites internal sprites Templates Template window definitions WimpLib Basic libary for the wimpy stuff words Text list of token words. *private Data this file constains a part of your personal password. Do not copy it along! Only the files marked with a * may be changed. All files should be copied along in their original versions. Version History Versions: 1.00 First release 1.01 better editor, more help. Wimp$Scrap improved, more hourglasses, default msg-name, autoscroll-tokens, bug in export to WL fixed 1.02 center windows, menu-option from, remove signature, center after mode change, escape implemented 1.03 full release version, more helptext, compact bug with ']' removed, preference pane bug removed, more messages, adjust on desk-icon, improved error trapping. improved 'assume-sender' options. pointer-changes (for RO3 only) implemented. 1.04 new password coding sheme, better tradeoff between mathematical security and 'guess-'secure. This means that only 'exact' token words code, others are ignored. See user_103 file! Solid-sprite-drag, checking of public list for hard coded key, loading window, info on public-keys and list Some hints of my brother implemented: Menu-icon added to the out tray, rather than that obscure d-clic to open the xfer/save-as window and menu-pressing on a menu-icon will not yield the normal menu but the specific one. Please note: This is a limited test version. A future version will utilize longer code sequences. For questions contact the author: : Dirk-Willem van Gulik Lionsight Residence Lipperkerkstraat 290 7533 AK Enschede The Netherlands Phone +31 53 303447 Email D.W.vanGulik@Student.UTwente.nl DWvGulik@Dialis.HackTick.nl This programme is uses the NUMBERS MODULE version 0.08 also (C) Copyright Nick Craig-Wood 1992 who remains the owner of the numbers module, see the file NumModTxt for any contrains and limitations imposed. *Signature [MQ{>}jeLs^m 6&V95( 9Y_b3q4u 9OY_{q 9XL^]